Existing procedures relating to the present invention are described in several Third Generation Partnership Project (3GPP) Technical Specifications. These include:    3GPP TS 33.220 v8.5.0 Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Generic bootstrapping architecture (Release 8);    3GPP TS 33.222 v8.0.0 Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS) (Release 8);    3GPP TS 33.246 v8.2.0 Technical Specification Group Services and System Aspects; 3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS) (Release 8); and    3GPP TS 26.237 v8.0.0 Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) based Packet Switched Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User Service; Protocols (Release 8).
FIG. 1 is a high-level reference model from TS 33.222 illustrating a Network Application Function (NAF) using a bootstrapping service. The network entities are defined in 3GPP TS 33.220, which specifies the Generic Bootstrapping Architecture (GBA) in which a mobile communication device such as a User Equipment (UE) 11 and a Bootstrapping Server Functionality (BSF) 12 run HTTP digest AKA over the Ub reference point and as a result establish a shared key Ks. The shared key Ks is later used to derive NAF-specific keys (called Ks_NAF keys) to secure communication between the UE and a NAF 13 over the Ua reference point. The NAF fetches the NAF-specific key over the Zn reference point.
3GPP TS 33.222 clause 6 specifies the use of an Authentication Proxy (AP) in the NAF 13. The AP is compatible with the GBA architecture specified in TS 33.220. When an AP is used in this architecture, the AP relieves the Application Server (AS) of security tasks by taking the role of a NAF.
FIG. 2 is a high-level reference model from TS 33.222 illustrating the environment and reference points of an Authentication Proxy (AP) 15. TS 33.222 assumes the use of Transport Layer Security (TLS) between the UE 11 and the AP 15 in the NAF 13. When an HTTPS request is destined towards an application server (AS) 16a-16n behind the AP, the AP terminates the TLS tunnel 17, fetches the NAF key (Ks_NAF) from the BSF 12, and performs UE authentication. The AP proxies the HTTP requests received from the UE to one or many ASs. The AP may add an assertion of identity of the subscriber for use by the AS, when the AP forwards the request from the UE to the AS.
A problem with the procedure defined in TS 33.222 for use of the NAF key is that the UE 11 and the ASs 16a-16n do not share any key material even though there could be cases where such shared key material would be needed. The AP 15 takes the role of a NAF 13 in TS 33.222. Therefore, the NAF key (Ks_NAF) is specific to the AP according to the key derivation rules specified in TS 33.220, and is not known by the UE.
FIG. 3 is a high-level reference model from TS 26.237 illustrating a current solution for key sharing. This problem defined above for use of the NAF key with the ASs is also applicable to the network entities defined in TS 26.237. In this case, the Service Control Function (SCF) 21 takes the role of a modified variant of an NAF/AP (and thus is labeled SCF/NAF), and the MBMS Broadcast/Multicast Service Center (BM-SC) 22 takes the role of an AS (and thus is labeled BM-SC/AS). Like the ASs in FIG. 2, the BM-SC/AS needs a shared key with the UE 11 in order to be able to send protected MIKEY key management messages directly from the BM-SC/AS to the UE over a unicast or broadcast channel.
It should be noted that TS 26.237 does not mention this analogy with the AP 15 and AS 16 of TS 33.222. The setting in TS 26.237 is not exactly the same as in TS 33.222; for example, a TLS tunnel between the UE 11 and SCF 21 is not necessarily used. However, similar problems remain.
In TS 26.237, a solution has been introduced in which the SCF 21 sends its own NAF key (Ks_NAF) to the BM-SC 22. The BM-SC uses the Ks_NAF as the MUK (MBMS User Key), which is used to protect the MIKEY key management messages from the BM-SC to the UE 11. Steps 1-6 of FIG. 3 are according to the current GBA procedures, and step 7 describes sending the Ks_NAF and an asserted identity of the subscriber to the BM-SC.
The current solution in TS 26.237 works fine as long as only one BM-SC 22 is connected to the SCF 21 (and as long as the SCF can assume enough trust towards the BM-SC so that the BM-SC does not misuse the SCF-specific NAF key). Problems arise when two or more BM-SCs are attached to the SCF. This is because according to the current solution, the SCF sends its own Ks_NAF to the BM-SC and therefore the SCF would send the same Ks_NAF to all the connected BM-SCs. It is not a good security practice to give the same key to several nodes. This would result in a situation where the same Ks_NAF key is used between the UE 11 and all related BM-SCs. This would open up threats such as the BM-SCs impersonating each other towards the UE.
FIG. 4 is a message flow diagram illustrating the messages sent between various network entities during an existing IMS-based MBMS registration procedure. The figure is based on the preconditions that the UE 11 has been registered and authenticated to IMS according to 3GPP TS 33.203; the UE has communicated with the Service Schedule Function (SSF) (not shown) and has received the list of available services as defined in 3GPP TS 26.237; the UE has run GBA bootstrapping with the BSF 12 as defined in 3GPP TS 33.220; and the network interfaces are protected with Network Domain Security (NDS/IP) as defined in 3GPP TS 33.210.
The procedure is as follows, with only relevant information on the security procedures shown. The UE 11 sends a SIP INVITE message 31 to the SCF 21 via the IP Multimedia Core Network (IM CN) subsystem 32. The INVITE message indicates “SCF” in the Request-URI and the message includes in an XML document in the SIP message body, the identities of the requested MBMS user services (userServiceIds) for which the UE wants to register. The XML document is the same as that used for MBMS Registration in TS 33.246, and it is specified in TS 26.346. Additionally, there is an XML document carrying a Bootstrapping Transaction Identifier (B-TID). The XML document carrying the B-TID is defined in Annex I of 3GPP TS 26.237.
The SCF 21 receives the IP address of the UE 11 and the asserted identity or identities of the UE from the headers of the SIP INVITE message 31. The SCF performs a check based on stored subscription information to determine whether the UE is authorized to access the requested MBMS user services. If the UE is authorized, the procedure continues; if not, the procedure is terminated. If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the SCF 21 runs a GBA usage procedure at 33 and 34 with the BSF 12 over the Zn reference point to fetch the NAF keys corresponding to the UE as defined in TS 33.220. The SCF derives the MBMS User Key (MUK) from the NAF key as defined in TS 33.246.
The SCF 21 sends an HTTP POST message 35 to the BM-SC 22. The SCF populates the HTTP POST message as follows:    the HTTP version shall be 1.1 which is specified in RFC 2616;    the base of the Request-URI shall contain the full BM-SC key management URI (e.g., http://bmsc.home1.net:1234);    the Request-URI shall contain a URI parameter “requesttype” that shall be set to “authorized-register”, i.e., the Request-URI takes the form of “/keymanagement?requesttype=authorized-register”;    the SCF may add additional URI parameters to the Request-URI;    X-3GPP-Asserted-Identity header, which includes the identities of the UE;    the HTTP header Content-Type shall be the MIME type of the payload, i.e., “application/mbms-authorized-register+xml”;    the HTTP payload shall contain an XML document including a list of one or more userServiceIds of MBMS User Services to which the UE wants to register, IP address of the UE, MEMS user key (MUK), and lifetime of the MUK. The XML schema of the payload is specified in Annex I of 3GPP TS 26.237    the SCF may add additional HTTP headers to the HTTP POST request.
The BM-SC 22 receives the HTTP POST message 35, verifies that the HTTP POST is valid, and extracts the request for further processing. Since the HTTP POST message came from the SCF 21 with asserted identities, the BM-SC does not need to authenticate the UE 11 because the UE has been authenticated by the IMS. Additionally, the HTTP POST message also indicates to the BM-SC that the SCF has authorized the UE to register to the indicated MBMS User Services.
The BM-SC stores the received information and returns an HTTP 200 OK message 36 to the SCF 21. The BM-SC shall populate HTTP 200 OK message as follows:    the HTTP status code in the HTTP status line shall be 200;    the HTTP header Content-Type shall be the MIME type of the payload, i.e., “application/mbms-register-response+xml”;    the HTTP payload shall contain an XML document that includes a list including one status code for each MBMS User Service. The XML schema of the payload is the same that is used for MBMS Registration in TS 33.246, and it is specified in TS 26.346.
The SCF 21 receives the HTTP 200 OK message 36 and includes the XML body from the HTTP 200 OK message into a SIP 200 OK message 37 and sends the SIP 200 OK message to the UE 11 via the IM CN subsystem 32. The BM-SC 22 can now start sending MIKEY MSK messages (protected with MUK) 38, MTK messages (protected with MSK) 39, and MBMS Data (protected with MTK) 40 to the UE for the indicated MBMS User Services according to procedures specified in TS 33.246.
The problem with this procedure is the same as that discussed above with respect to FIG. 3, that is, there is no way to provide BM-SC-specific NAF keys if more than one BM-SC is connected to the SCF. If the SCF 21 sends the same Ks_NAF to all the connected BM-SCs, the same Ks_NAF key would be used between the UE 11 and all related BM-SCs. This would open up threats such as the BM-SCs impersonating each other towards the UE.
Additionally, there is not enough information in the MIKEY MSK message 38 to indicate to the UE 11 which MUK (i.e., NAF key) was used to protect the MIKEY MSK message. In MBMS TS 33.246, the NAF-Id and B-TID are used to indicate this; but in TS 26.237, the BM-SC 22 does not act as a NAF and therefore it does not have this information.